Domain Object

OOPの話をされることが多いが、FPでも同じ

OOPなら、classの設計方針

FPなら、module(型と関数のまとまり)の設計方針

の話になる

データと機能を同じ場所に書く

データの加工、計算のロジックを一箇所に集約する

業務の関心事と、コードを対応させる

業務のルールに変更があった時に、変更の影響を狭い範囲に閉じ込める

そのデータを使うロジックはDomain Object内に書く

Domain Objectの利用者は、その値をただ使用するだけ。

class名は業務に使っている用語を使う

ロジックのためだけにmethodを作る

何かしらの計算をした結果を返すようにmethodを作る

ただ値を返すだけということは、class外でそれを使って計算しているのでは、ということにつながる

その値を使った計算はDomainObject内に含めるべき

なぜならgetterを取得時に修正したくなった時にこっちのほうが楽だから

getter経由で基本はそのまま返して、たまに計算して返そう、という普通に読めてしまう

まあこれはmodelingの本ではなく、OOP入門の本だから仕方ないのか(?)

その値の計算に、Entity外の情報が必要な場合はどうするのか？

そのデータは計算前の情報である必要があったりはしないのか？

それともDIかなにかで流し込むのか？

使う側のクラスには業務ロジックを書かない

書いていたら適宜見直して別クラスに移動

これって型がないと割と厳しい気もする

テストは必須だろう

修正によるデグレをビビっている状況にあることがもう問題

この「書き直し」をいかに楽できるように工夫するか、がポイントになってくる

関連性の強いクラスはパッケージで整理していく

パッケージとはclassの集合のこと

増えてきたclassを何かしらの指標でまとめたものがパッケージ

参考